Skip to content

Conversation

@hyongtao-code
Copy link
Contributor

@hyongtao-code hyongtao-code commented Jan 31, 2026

Long log:

In free-threaded builds, setiter_len() and setiter_iternext() could race with concurrent set mutation and iterator exhaustion.

We now serialize operations on the iterator itself (and keep the set stable) using a critical section, and ensure the iterator’s exhaustion state is handled consistently.

The non-free-threaded build keeps the existing semantics. Add free-threading-style concurrency tests (similar to the itertools FT tests) to exercise __length_hint__ and iternext exhaustion under concurrent execution.

setiter_len() was reading so->used without atomic access while concurrent
mutations update it atomically under Py_GIL_DISABLED.

In free-threaded builds, setiter_len() could race with concurrent set
mutation and iterator exhaustion.

Use an atomic load for so->used to avoid a data race. This preserves the
existing semantics of __length_hint__ while making the access thread-safe.

Signed-off-by: Yongtao Huang yongtaoh2022@gmail.com

setiter_len() was reading so->used without atomic access while concurrent
mutations update it atomically under Py_GIL_DISABLED.

Use an atomic load for so->used to avoid a data race. This preserves the
existing semantics of __length_hint__ while making the access thread-safe.

Signed-off-by: Yongtao Huang <yongtaoh2022@gmail.com>
@hyongtao-code hyongtao-code changed the title gh-144356: fix data race in setiter_len() under no-gil gh-144356: Avoid races when computing set_iterator.__length_hint__ under no-gil Feb 1, 2026
@hyongtao-code
Copy link
Contributor Author

Thanks for the review. I’ve decided to address both issues in this PR. I also added a corresponding test case for the issue you pointed out.

Copy link
Contributor

@eendebakpt eendebakpt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some more review comments. I think we can get this right, but a simpler approach here would be to put a critical section on the set iterator itself.

@hyongtao-code
Copy link
Contributor Author

put a critical section on the set iterator

Thanks for the suggestion. I simplified the implementation by protecting both the iterator and the set with Py_BEGIN_CRITICAL_SECTION2(self, so), so concurrent use of the same iterator is properly serialized. This keeps the logic aligned with other iterators and avoids the races.

It looks like there is an unrelated flaky test case.

Copy link
Contributor

@eendebakpt eendebakpt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hyongtao-code Thanks for your work on this! The core idea of the PR has shifted a bit, which is why I have some more review comments, but we are getting closer I believe.

hyongtao-code and others added 2 commits February 9, 2026 19:09
Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
@hyongtao-code hyongtao-code changed the title gh-144356: Avoid races when computing set_iterator.__length_hint__ under no-gil gh-144356: Make set iterator __length_hint__ and iternext race-safe under no-gil Feb 10, 2026
Comment on lines +1060 to +1074
#ifdef Py_GIL_DISABLED
PySetObject *so = si->si_set;
assert(so != NULL);

Py_BEGIN_CRITICAL_SECTION2(op, so);
if (si->si_pos >= 0 && si->si_used == so->used) {
len = si->len;
}
Py_END_CRITICAL_SECTION2();
#else
if (si->si_set != NULL && si->si_used == si->si_set->used) {
len = si->len;
}
#endif

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#ifdef Py_GIL_DISABLED
PySetObject *so = si->si_set;
assert(so != NULL);
Py_BEGIN_CRITICAL_SECTION2(op, so);
if (si->si_pos >= 0 && si->si_used == so->used) {
len = si->len;
}
Py_END_CRITICAL_SECTION2();
#else
if (si->si_set != NULL && si->si_used == si->si_set->used) {
len = si->len;
}
#endif
PySetObject *so = si->si_set;
Py_BEGIN_CRITICAL_SECTION(op);
if (si->si_pos >= 0 && si->si_used == FT_ATOMIC_LOAD_SSIZE_RELAXED(so->used)) {
len = si->len;
}
Py_END_CRITICAL_SECTION();

This is less code and a bit more efficient (only a single lock):

From the set object so = si->si_setwe only need to read the fieldusedwhich we can do with an atomic load. In the FT buildsois never NULL. In the non-FT buildsocan only be NULL ifsi->si_set < 0`)

@hyongtao-code I did not test the above suggestion

else {
/* exhausted */
si->si_pos = -1;
si->len = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this needed?

if (key == NULL) {
si->si_set = NULL;
/* exhausted */
Py_DECREF(so);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you move the decref to the section

       /* exhausted */
        si->si_pos = -1;
        si->len = 0;

?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants